In a mobile (cellular) communications network, (user) communication devices (also known as user equipment (UE), for example mobile telephones) communicate with remote servers or with other communication devices via base stations. In their communication with each other, communication devices and base stations use licensed radio frequencies, which are typically divided into frequency bands and/or time blocks.
In order to be able to communicate via the base stations, communication devices need to monitor control channels operated by the base stations. One of these physical control channels, the so-called physical downlink control channel (PDCCH) carries control information for scheduling of downlink and uplink resources to individual communication devices. Physical downlink control (PDCCH) channels are transmitted on an aggregation of one or several consecutive control channel elements (CCEs). Scheduling is realised by the serving base station transmitting, over the PDCCH, a Downlink Control Information (DCI) to each communication device that has been scheduled resources in the current scheduling round. Downlink data that has been scheduled this way is transmitted over the so-called Physical Downlink Shared Channel (PDSCH) using the resources allocated by the DCI. The PDSCH resources associated with the PDCCH control information (DCI) are normally provided within the same subframe, albeit using different frequencies.
The so-called physical uplink control channel (PUCCH) carries, in the uplink from the communication device to the serving base station, information referred to as Uplink Control Information (UCI). The UCI includes, amongst others, the so-called Hybrid Automatic Repeat Request (HARQ) feedback which is generated by the communication device and sent to the serving base station in response to downlink data transmissions received over the resources specified by the DCI. The UCI may also include channel quality indication (CQI), although this is optional. Normally, PUCCH resources are allocated to each communication device such that each communication device has time for processing the received downlink data before sending an appropriate (HARQ) Ack/Nack. Typically, PUCCH resources are allocated in the fourth subframe following transmission of the corresponding downlink data over the PDSCH, leaving a total of three subframes for processing the received data and generating an Ack/Nack.
The more communication devices there are in a cell and the more data is communicated for these communication devices, the more control signalling and HARQ feedback needs to be transmitted. Therefore, the amount of resources allocated for the PUCCH may change in dependence on the number of communication devices served by the base station.
In the Rel-13 version of the LTE standards, it is envisioned that the PUCCH will be provided in accordance with the current (Rel-8 based) design. In particular, the current PUCCH design specifies, amongst others, that:                the PUCCH is located at an edge of the total available cell bandwidth and that PUCCH slot hopping can also be applied (slot hopping is a technique for improving frequency diversity by frequently alternating the location of the PUCCH physical resources between opposite edges of the cell bandwidth); and        the number of physical resource blocks (PRBs) in a slot that is available for potential PUCCH transmission is configured by higher layer signalling using the ‘push-HoppingOffset’ parameter.        
However, recent developments in telecommunications have seen a large increase in the use of machine-type communications (MTC) UEs which are networked devices arranged to communicate and perform actions without human assistance. Examples of such devices include smart meters, which can be configured to perform measurements and relay these measurements to other devices via a telecommunication network. Machine-type communication devices are also known as machine-to-machine (M2M) communication devices.
MTC devices connect to the network whenever they have data to send to or receive from a remote ‘machine’ (e.g. a server) or user. MTC devices use communication protocols and standards that are optimised for mobile telephones or similar user equipment. However, MTC devices, once deployed, typically operate without requiring human supervision or interaction, and follow software instructions stored in an internal memory. MTC devices might also remain stationary and/or inactive for a long period of time. The specific network requirements to support MTC devices have been dealt with in the 3GPP TS 22.368 standard, the contents of which are incorporated herein by reference.